A FunnelFlux Pro számos erőforrással rendelkezik, amelyek szükséges előfeltételei egy tölcsér felépítésének és egy teljes funkcionalitású kampány futtatásának.
Ezek a következők:
- Forgalmi források
- Ajánlati források
- Ajánlatok
- Céloldalak
- Egyedi domain (nem igazán erőforrás, de szükséges)
Az alábbiakban ezeknek az elemeknek a konfigurációját és a követési folyamatokra gyakorolt hatásukat mutatjuk be.
Forgalmi források
A forgalmi forrás határozza meg a bejövő látogatók forrását, és ezt kell kiválasztani a kampány URL-ek létrehozásakor.
A forgalmi forrás konfigurációjának két fő összetevője van:
- Az URL követési mezők
- Konverzió követés
URL követési mező konfiguráció
Lásd az alábbi képet:
A FunnelFlux 20 egyéni követési mezőt tesz lehetővé, amelyek mindegyikének rendelkeznie kell egy névvel (alias) és egy opcionális helykitöltő értékkel. A bal oldali számok az adatbázis oszlopszámait jelölik. Így ez a konfiguráció aliasokat hoz létre a név -> oszlopazonosító leképezéshez.
A követési mező konfigurációt az átirányítási/közvetlen linkek generálásakor használjuk - ezek a mezők határozzák meg a forgalmi forrásra jellemző lekérdezési karakterlánc adatokat, amelyeket az URL-hez fűzünk.
Két fenntartott mezőnk van, amelyeket nem lehet eltávolítani, de lehet aliasokat adni nekik - a kampány és a külső.
Ezek a kampányazonosító értékek (vagy kampánynév) és a kattintáskövetési azonosítók számára vannak fenntartva.
A helykitöltőknek mind azoknak a tokeneknek/makróknak kell lenniük, amelyeket a forgalmi forrás elemez (mivel ezek olyan URL-ekben szerepelnek, amelyeket várhatóan a forgalmi forrásnál használnak), a FunnelFlux token pedig az a tokenformátum, amely a céloldal/ajánlat URL-ekben használható a forgalmi forrás adatainak továbbításához.
Hasznos megjegyzések
- A forgalmi források nem feltétlenül reklámplatformok - létrehozhat forgalmi forrást e-mailekhez, az e-mail összefűzési címkéket használva tokenként. Létrehozhat forgalmi forrásokat konkrét partnerek számára is, manuálisan létrehozott mezőkkel, és hagyhatja, hogy a felhasználó statikus adatokat adjon meg. Ilyenkor a legjobb gyakorlat, ha a helykitöltőt REPLACE-re állítja, hogy csökkentse az emberi hibákat a linkek használatakor.
- Ha egy követési mező helykitöltője üresen marad, kihagyjuk a generált URL-ből, de a mező továbbra is rögzítésre kerül, ha az URL-adat létezik.
- Néhány esetben értelmes lehet a fenntartott mezőinket feloldani és átnevezni, ahol a kampány vagy kattintási azonosító automatikusan hozzáadódik az URL-ekhez - például a Facebook automatikusan hozzáfűzi az "FBCLID"-t. A sablonunkban a külső mező FBCLID-re van átnevezve, és üres helykitöltőt kap. A rendszerünk így NEM adja hozzá az FBCLID= -t a generált URL-ekhez, de rögzíti a bejövő FBCLID lekérdezési karakterlánc paraméter értékeit, és külső kattintási azonosítóként tárolja őket.
- A felhasználók bármikor átnevezhetik a mezőket, és ez ahhoz vezethet, hogy a számozott oszlopba történő adatnaplózás hirtelen megváltozik egy adott időpontban, ezért ügyelni kell arra, hogy a beállítás után ne változtassuk meg jelentősen az egyes oszlopszámokba beérkező adatokat. Ehelyett jobb lenne archiválni azt a számozott sort és új mezőt létrehozni, vagy új forgalmi forrást használni.
- Az archivált követési mezők nem láthatóak és nem jelennek meg a jelentési legördülő menükben, de továbbra is megjelennek az adatokban. Ha új sort hozunk létre ugyanazzal a névvel, mint egy archivált mező, az a mező archívum helyett visszakerül, nem pedig duplikált mezőt hoz létre, mivel az archivált mező továbbra is rögzíti és tárolja az adatokat, ha az URL-ek használják.
- A mezők átnevezésekor egy previousName értéket tárolunk a régi link URL-adatok átnevezett értékekre való leképezéséhez.
Konverziókövetési konfiguráció
Itt a felhasználók beállíthatják a konverziós adatok forgalmi forráshoz való visszajuttatásának módját.
A Postback URL-ek egyszerű GET kérések a forráshoz, amelyek továbbítják a szükséges adatokat és a rendelkezésre álló kattintási azonosítóhoz tartozó {external} tokenünket.
A HTML lehetővé teszi JS vagy kép pixelek használatát. Ehhez a felhasználóknak a JavaScript követésünkkel kell rögzíteniük a konverziót, amely az oldalra továbbítja a HTML-kódot, ha be van állítva.
Az egyedi forgatókönyvek egyedi integrációk, amelyeket különböző forgalmi forrásokhoz hoztunk létre, és általában egy API-t tartalmaznak.
A felhasználóknak a beállítási részletekért a súgó dokumentációnkat kell tanulmányozniuk. Ezeket érdemes kihasználni, ha rendelkezésre állnak, mivel sokkal megbízhatóbb követést biztosítanak. Mindegyik szerver-szerver alapú, így működnek, ha a konverziókat postback URL-ekkel továbbítják a FunnelFluxnak, de akkor is, ha a konverziókat JS-sel indítják el.
Ajánlati források
Ezek határozzák meg az ajánlatok forrását, amelyek általában partner hálózatok. Bár egy felhasználó létrehozhat olyan forrásokat is, mint "Saját termékek" vagy egy webhelynév.
Ezek három célt szolgálnak:
- Adattovábbítási sablonok készítése, mivel amikor egy ajánlat ezt a forrást használja, örökli az adattovábbítási konfigurációt
- Postback URL-ek sablonozása, hogy a felhasználók könnyen másolhassák/beilleszthessék az URL-eket a hálózatokba
- Általános kategóriaként a jelentéskészítéshez
Megjegyzés: a közeljövőben tervezzük frissíteni az adattovábbítási paradigmánkat. Jelenleg az ajánlati forrás konfigurációját egyirányúan örökli az ajánlat konfiguráció kiválasztásakor. Ha a felhasználó frissíti az ajánlati forrást, az ajánlatokban nem történik változás. A jövőben szigorú öröklést hozunk létre, ahol az ajánlatok először öröklik az adattovábbítási konfigurációt a forrásból (és néhány egyéb konfigurációt), majd az ajánlat szintjén további mezők állíthatók be, valamint felülírások.
Adattovábbítás
Itt a felhasználók űrlapalapú megközelítést alkalmazhatnak az általános beállítások alatt található alap oldal URL-hez fűzött lekérdezési karakterlánc létrehozásához.
Ez a megközelítés csökkenti az emberi hibákat, és lehetővé teszi számunkra az adattovábbítás jobb sablonozását.
A legjobb gyakorlat szerint az alap oldal URL-nek tartalmaznia kell minden olyan statikus URL-adatot, amely soha nem változik. A partner URL-ek esetében ez gyakran magában foglalja valamilyen partner/ajánlat azonosítót.
Ideális esetben minden dinamikus adatot az adattovábbítási szakaszon keresztül kell konfigurálni.
Hasznos megjegyzések
- Néhány mezőnév korlátozott, mint például vid, n, c, ts stb., amelyeket a FunnelFlux vagy a JavaScript által továbbított fenntartott paraméterekhez használunk
- URL-adatok továbbításához kiválaszthatja ezt az opciót, majd csak a lekérdezési karakterlánc kulcsnevét kell megadnia. Mentéskor az elem
{data-url_key_name}formára zsugorodik - ezt később tervezzük továbbfejleszteni. - Vegye figyelembe, hogy a követési linkekben továbbított adatokat ezzel a tokennel lehet elérni, csakúgy, mint az URL pufferünkbe továbbított lekérdezési karakterlánc adatokat. Azaz bármely URL lekérdezési karakterlánc adat, amelyet egy átirányítási vagy művelet linkbe továbbítunk, és amely NEM definiált követési mező, továbbra is tárolódik a munkamenet adatokban, és elérhető a
{data-url_key_name}tokennel. Azonban nem lesz elérhető a jelentésekben. - Összetett vagy egyéb adatok továbbításához válassza az egyéni karakterláncot. Itt a szokásos módon használhatja a tokeneket, így például
{funnel-id}-{campaign}-{trafficsource-id}. Ha összetett adatokat, például URL-karakterláncot továbbít, nem kell kódolni, mivel rendszerünk automatikusan URL-kódolja mentéskor.
Konverziókövetés
Ez a szakasz meglehetősen magától értetődő.
A postback URL sablonozásához adja meg a bevétel/opcionális tranzakció azonosító tokeneket, amelyeket az ajánlat forrás platformja elemez és helyettesít.
A találati azonosítóhoz jelölje be azt a mezőt, amelybe a {hit} értékünket továbbítja az adattovábbításnál. Ha például "aff_sub5", akkor a konverziókövetési oldalon be kell írnia az ajánlati forrás megfelelő tokenjét, amely a tárolt aff_sub5 értéket képviseli, pl. {aff_sub5}
Hasznos megjegyzések
- Az azonos találati azonosítóval és TxID értékekkel a FunnelFluxhoz továbbított konverziók jelenleg lecserélik a meglévő konverziót, de nem okoznak duplikálást. Jelenleg ez frissíti a konverzió időbélyegét. Azt tervezzük, hogy ezt a funkciót úgy cseréljük le, hogy NE frissítse az eredeti időbélyeget, így az új esemény, ha duplikátum, lényegében figyelmen kívül marad.
- Jelenleg a konverziókövetés nem szűri ki a duplikátumokat a forgalmi forráshoz küldött események tekintetében. Tehát még ha a FunnelFlux belül deduplikálja is a konverziót, az esemény továbbra is elküldésre kerül a forgalmi forráshoz. Ezt a viselkedést is frissíteni tervezzük, hogy ne küldjön duplikált eseményeket.
- Így ha a felhasználók több legitim konverziót szeretnének indítani, mindig egyedi tranzakció-azonosító értékeket kell megadniuk a postback URL/JS "tx" paraméterén keresztül.
Ajánlatok
Az ajánlatoknak ki kell választaniuk egy ajánlati forrást, hogy először örököljék a fontos konfigurációt, időt takarítva meg és csökkentve az emberi hibákat.
Az ajánlatnak ezután van egy alap URL-je, amely minden statikus adatot tartalmaznia kell, és minden dinamikus adat az adattovábbítási szakaszon keresztül kerül továbbításra.
Amikor a FunnelFlux egy ajánlatra irányít át, az alap URL-re + adattovábbítási konfiguráció = végső ajánlat URL-re irányít át.
Az ajánlat kategóriák kizárólag a jelentésekben való csoportosításra szolgálnak, és nincs funkcionális hatásuk.
Oldal művelet linkek
Ezek az oldalakon használandó művelet (CTA) URL-ek. Általánosak és a következő formátumúak:
https://DOMAIN/action/number
A FunnelFluxban az oldalakon lévő átkattintási URL-ek (művelet linkek) nem határozzák meg a célt. Egy végrehajtandó "műveletre" hivatkoznak. Kattintáskor a FunnelFlux feldolgozza az aktuális felhasználó tölcsér konfigurációját, és az aktuális ismert csomópont pozíciója alapján végrehajtja az X műveletet abból a csomópontból.
Ily módon a FunnelFlux nem jelzi előre a felhasználó következő célállomását, és így nem lehetséges olyan linket létrehozni egy oldalon, amely átkattintást/műveletet hoz létre, de egy bizonyos csomópontra való átirányítást is kikényszerít.
Természetesen lehet feltételes csomópontot használni, és a művelet URL-be továbbított URL-adatok alapján útválasztani, de ez egy külön funkció - a céloldalról induló művelet továbbra is természetesen a következő várható csomópontra (ebben az esetben egy feltételre) irányulna.
Megjegyzendő, hogy a művelet linkek általánosak, és nem kell konkrétan az oldalra, tölcsérre vagy forrásra vonatkozniuk. A tölcsér építőben ezek a műveletek alapértelmezett paraméterekkel is lekérhetők. Ezt a tölcsér technikai dokumentumban tárgyaljuk.
Integrációs termékazonosítók
Ez egy béta szakaszban lévő rész - kifejezetten azokhoz a webhook integrációkhoz készült, amelyeket tervezünk építeni, és amelyek termékazonosítókat és látogatói azonosítót továbbítanak. Ha egy ajánlathoz termékazonosítók vannak beállítva, akkor kereszthivatkozással meghatározhatjuk, hogy X termékazonosító Y ajánlatnak felel meg -- ez az az ajánlat, amely konvertált. Jelenleg korlátozott a felhasználása.
Céloldalak
Az ajánlatokhoz hasonlóan egy céloldal is csak egy oldal.
A fő különbségek az ikon/név mellett az, hogy a céloldalnak nincs "forrása", amelyből örökölné a konfigurációt
A céloldalakat minden olyan oldalra használni kell, amely nem fog közvetlenül bevételt generálni a felhasználó azon az oldalon végrehajtott műveletéből vagy abból származóan.
Például egy fizetési oldal valószínűleg egy ajánlat oldal lenne - de az előző termék értékesítési oldal egy céloldal lenne, mivel a fizetési oldal az a hely, ahol a felhasználó végül konvertál.
Minden olyan oldal, amely végpont, ahol a látogatót valamilyen harmadik félhez irányítják át, pl. egy partner hálózathoz, biztosan ajánlat, nem céloldal.
Megjegyzendő, hogy bár a céloldalak nem konvertálnak, a jelentésekben továbbra is öröklik a felhasználók által az útjuk későbbi szakaszában generált bevételeket és konverziókat.